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SUMMARY 


The  Advanced  On-the-job  Training  System  (AOTS)  was  an  Air  Staff  directed, 
AFHRL  developed,  prototype  system  which  designed,  developed,  and  tested  a 
proof-of-concept  prototype  AOTS  within  the  operational  environment  of 
selected  work  centers  at  Bergstrom  AFB,  Texas,  and  Ellington  ANGB,  Texas, 
from  August  1985  through  31  July  1989.  The  AOTS  Configuration  Management 
Plan  describes  the  technical  and  managerial  approach  used  for  conducting  the 
AOTS  Configuration  Management  effort.  Configuration  Management  is  the  means 
through  which  the  integrity  and  continuity  of  design,  engineering  and  cost 
trade-off  decisions  made  between  technical  performance,  and  operability  and 
supportabil ity  are  recorded,  communicated,  and  controlled  by  program  and 
functional  managers.  As  such,  the  AOTS  configuration  management  documents 
and  controls  the  entire  development  process.  The  AOTS  Configuration 
Management  Plan  addresses:  Configuration  Management  Organization, 
Configuration  Identification,  Configuration  Control,  Software  Configuration 
Authentication,  Configuration  Status  Accounting,  Interface  Management, 
Configuration  Audits,  Subcontractor/Vendor  Control,  and  Configuration 
Management  Major  Milestones. 
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PREFACE 


This  paper  was  prepared  by  Douglas  Aircraft  Company,  the  AOTS  Development 
contractor,  under  Government  Contract  Number  F33615-84-C-0059.  The  AFHRL 
Work  Unit  number  for  the  project  Is  2557-00-02.  The  primary  office  of 
responsibility  for  management  of  the  work  unit  is  the  Air  Force  Human 
Resources  Laboratory,  Training  Systems  Division,  and  the  Air  Force  AOTS 
manager  is  Major  Jack  Blackhurst. 

The  Advanced  On-the-job  Training  System  (AOTS),  systematically  applies 
state-of-the-art  technology  to  Air  Force  On-the-Job  Training  (OJT).  The  AOTS 
comprises  five  subsystems,  each  of  which  includes  a  set  of  related  components 
designed  to  accomplish  those  functions  required  for  the  development  a.,d 
operation  of  an  effective  OJT  system.  The  five  systems  comprising  the  AOTS 
are:  (a)  management;  (b)  evaluation;  (c)  computer  support;  (d)  personnel 
and  support;  and  (e)  training  development  and  delivery.  Within  the  AOTS,  the 
Training  Development  and  Delivery  Subsystem  is  intended  to  operate,  and  will 
be  designed  to  operate  as  an  independent  subsystem.  The  contractor  shall 
design,  develop,  implement,  demonstrate,  and  test  the  AOTS  system,  sub¬ 
systems,  and  their  components.  The  Government  will  provide  an  Air  Force 
technical  team.  Instructional  System  Team  (1ST),  to  be  collocated  with  the 
contractor.  All  evaluation  Instruments  and  curriculum  materials  used  within 
the  prototype  AOTS  will  be  developed  by  the  1ST.  The  AOTS  subsystems  shall 
be  integrated  into  a  total  functional  system,  which  will  be  demonstrated  and 
tested  in  order  to  determine  Its  operational  capabilities  as  a  prototype  OJT 
system.  The  AOTS  capabilities  required  Include:  identification  of  perfor¬ 
mance  and  training  requirements;  management  of  training.  Including  job-site 
training  delivery;  evaluation  of  airman  task  performance;  evaluation  of 
program  effectiveness;  and  OJT  management  analysis  data  output  to  appropriate 
Air  Force  training  management  levels. 
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1 .  INTRODUCTION 


1.1.  Purpose  and  Scope 

This  AOTS  Configuration  Management  Plan  describes  the  technical 
and  managerial  approach  used  for  conducting  the  Advanced  On-the- 
Job  Training  System  (AOTS)  Configuration  Management  (CM)  effort. 

The  Plan  establishes  the  organizational  responsibilities  and 
interfaces,  the  sequence  of  major  events,  and  reporting  tools 
required  to:  identify  and  document  the  AOTS  baseline 

configuration;  control  changes  to  the  baseline;  track  the  status 
of  configuration;  and  prepare  and  submit  contractually  required 
program  data. 

1.2.  Definitions 

Terms  not  defined  in  the  body  of  this  plan  are  per  the 
definitions  of  DOD-STD-480A  Appendix  E,  MIL-STD-482,  and  MDAC  | 
Control  Procedure  2.001  (see  Appendix  B) .  | 

1.3.  Configuration  Management  Summary 

AOTS  Configuration  Management  (CM)  provides  the  formal  structure 
and  discipline  needed  to:  (1)  identify,  track,  control,  and 

trace  the  AOTS  design  and,  (2)  assess  and  document  the  impact  of 
proposed  changes. 

CM  is  the  means  through  which  the  integrity  and  continuity  of 
design,  engineering  and  cost  trade-off  decisions  made  between 
technical  performance,  operability  and  supportability  are 
recorded,  communicated  and  controlled  by  program  and  functional 
managers.  As  such,  the  CM  function,  documents  and  controls  the 
entire  development  process.  CM  benefits  the  AOTS  Program  in 
three  ways: 

a.  It  provides  precise  identification  of  the  configuration 
of  each  configuration  item. 

b.  It  produces  results  through  the  identification  of 
baselines  and  changes  to  them,  thus  permitting  analysis 
and  correction. 

c.  It  provides  a  formal  structure  for  assessing  impacts  of 
proposed  changes. 

d.  Capable  of  handling  expedited  changes. 

Technical  and  administrative  controls  will  be  applied  by  AOTS  to 
define  and  evaluate  the  total  system  effect  of  all  proposed 
changes  to  established  baselines.  The  AOTS  Configuration  Control 
System  is  the  first  line  authoring  agency  for  preparation  of 
proposed  changes,  analysis,  tracking  the  progress  of  changes, 
approval/disapproval,  planning,  co-ordination  and  implementation  ! 
of  approved  changes  to  established  baselines.  All  AOTS  CCB  | 
approved  Class  1  Changes  will  be  forwarded  to  AFHRL  on  a 


Version  1.01 


Page  1 


Engineering  Change  Proposal  (ECP)  for  handling  in  accordance  with 
the  AOTS  CM  Plan.  (See  section  5. 2. 2. 3  Change  Classification  for 
definition  of  Class  1  Changes.)  The  AOTS  CCB  will  be  co-chaired 
by  the  AFKRL  chief  and  the  AOTS  Program  Manager  or  their 
designees.  Approved  baseline  changes  will  be  classified, 
prepared,  and  submitted  under  the  guidelines  of  DoD-STD-480A  and 
MIL-STD-482,  Configuration  Control  -  Engineering  Changes, 
Deviations  and  Waivers,  as  modified  by  the  Statement  of  Work 
(SOW) ,  and  implemented  by  procedures  described  herein. 

AOTS  CM  will  provide  interim  configuration  status  accounting 
reports  during  development. 

This  Configuration  Management  Plan  (CMP)  addresses  the  following 
areas : 


-  Configuration  Management  Organization 

-  Configuration  Identification 

-  Configuration  Control 

-  Software  Configuration  Authentication 

-  Configuration  Status  Accounting 

-  Interface  Management 

-  Configuration  Audits 

-  Subcontractor/Vendor  Control 

-  Configuration  Management  Major  Milestones 
1.4.  System  Integration 


Section  3.0 
Section  4.0 
Section  5.0 
Section  6.0 
Section  7.0 
Section  8.0 
Section  9.0 
Section  10.0 
Section  11.0 


1.4.1.  Approach  and  Task 

The  AOTS  system  integration  task  has  been  tailored  to  the 
requirements  of  the  AOTS  program  and  AOTS  engineering  effort. 
The  approach  is  iterative  and  consists  of  various  overlapping 
elements  as  defined  in  the  AOTS  Software  Development  Plan. 

1.4.2.  Configuration  Management  Integration 
1.4.2. 1.  Baseline  Establishment 

Baseline  establishment  is  described  in  section  4.1. 
o  Integration 

The  initial  software  and  hardware  will  be  integrated, 
tested,  and  installed  in  accordance  with  the  Detail 
Specification,  Software  Development  Plan,  System 
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Engineering  Management  Plan,  and  the  Software  Test  | 

Plan.  j 

o  Development  Test  &  Evaluation 

AOTS  hardware  and  software  will  be  subject  to 
System  Level  Testing  and  Evaluation  (SLT&E) .  The  results 
of  these  tests  will  be  recorded  and  analyzed  for 
technical  performance.  Test  results  will  be  used  to 
correct  defects  prior  to  final  integration  and  release. 

Test  results  will  also  be  reviewed  with  respect  to  system 
validation  for  operational  evaluation. 

2.  APPLICABLE  DOCUMENTS 

The  following  documents  and  associated  references  will  be  used  as 
guidance  for  the  AOTS  Configuration  Management  Plan  only  to  the 
extent  specified  herein.  The  Military  standards  are  to  be  used 
for  guidance  only  unless  so  required  in  the  SOW  or  the  A 
specification  (70S647000) . 


MILITARY  STANDARDS 

ISSUE  DATE 

TITLE 

DoD— D-100C 

31  OCT 

80 

Numbering,  Coding,  and 
Identification 

MIL— S- 52 779 A 

01  AUG 

79 

Software  Quality  Assurance 
Program  Requirements 

DoD-STD— 480A 

12  APR 

78 

Configuration  Control- 
Engineering  Changes, 
Deviations  &  Waivers 

MI L-STD-4  8 1A 

12  OCT 

72 

Configuration  Control-  | 
Engineering  Changes,  | 
Deviations  and  Waivers  | 
(Short  Form)  j 

MIL-STD-482A 

1  Apr. 

74 

Configuration  Status  I 
Accounting  Data,  I 
Elements  and  Related  j 
Features  I 

MIL-STD-483A 

4  JUN 

85 

Configuration  Management 
Practices  for  Systems, 
Equipment,  Munitions,  and 
Computer  Programs 

MIL-STD-490A 

4  JUN  85 

Specification  Practices 

MIL-STD-152 1A 

21  DEC 

81 

Techpical  Reviews  and  Audi 
for  Systems,  Equipment  and 

Version  1.01 


Page  3 


Computer  Programs 

-  MIL-STD-1679A  22  OCT  83  Software  Development 

CDRLs  contain  relivant  data  for  the  Configuration  Management  | 
System  and  are  listed  here  for  reference.  All  CDRL  deliverable  j 
items  will  be  controlled  by  the  CM  system.  | 


CDRL  ITEMS 
1 
2 

3 

4 

5 

6 
8 
9 

10 

11 

13 

14  ■ 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 


TITLE 

R  &  D  Status  Report 

Cost/Schedule  Status  Report  (C/SSR) 

Presentation  Material 

Informal  Technical  Information 

Data  and/or  Analysis  Summary 

Abstract  of  New  Technology  (ANT) 

System/ Design  Trade  Study  Reports 

Technical  Reports/Interim  Reports 

Technical  Reports/Final  Reports 

Contract  Work  Break  down 

Progress/Status  Meeting  Report 

Project  Status  Report,  Computer  Software 

Engineering  Change  Proposal  (ECP) 

Commercial/Computer  and  Peripheral  Equipment 
Manuals 

Computer  Software  Test  Plan 
Computer  Program  Test  Report 
Configuration  Management  Plan  (CMP) 

Computer  Program  Standard 

Computer  Software  Test  and  Evaluation  Reports 

Minutes  of  Formal  Reviews,  Inspections  and 
Audits 

Software  Development  Plan 
Procedural  Guide 
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25 

Software  System  (User  Manual) 

26 

System  Engineering  Management  Plan 

(SEMP) 

27 

System  Specification 

28 

Configuration  Item  Development  Specification 

29 

Master  Test  Plan/Program  Test  Plan 

(MTP) 

30 

Site  Preparation  Requirements  Equipment 
Installation  Plan 

31 

Maintenance  Plan 

32 

Computer  System  Operational  Manual 

33 

Maintainability  Program  Plan 

34 

Reliability  Program  Plan 

35 

Human  Engineering  Program  Plan 

36 

Contract  Funds  Status  Report 

37 

Computer  Software/ Computer  Program/Computer 
Data  Base  Configuration  Item(s) 

AOTS  developed  specifications  will  define  aspects  of  the  | 
Configuration  Management  requirements  and  they  in  turn  will  be  | 
controlled  by  the  CM  system.  | 


AOTS  SPECIFICATION 

DATED 

DESCRIPTION 

70S647000 

May  5,  1986 

AOTS  System 

70S647I00 

Management  Subsystem 

7  0S647200 

Training  Development  and 
Delivery  Subsystem 

70S647201 

Training  Development 
Component 

70S647202 

Training  Delivery 

Component 

70S647300 

Evaluation  Subsystem 

70S647400 

Computer  Support  Subsystem 

70S647401 

Hardware  Component 
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70S647411B 

70S647412B 

70S647413B 

70S647414B 

70S647500 

70S647411C 

70S647412C 

70S647413C 

70S647414C 

Note:  Specifications  with  a  s 

refers  to  the  C5  specications. 


Management  CPCI 

Training  Development  and 
Delivery  Subsystem 

Evaluation  CPCI 

System  Support  CPCI 

Personnel  and  Logistics 
Support  Subsystem 

Management  CPCI 

Training  Development  and 
Delivery  Subsystem 

Evaluation  CPCI 

System  Support  CPCI 

of  "B"  refer  to  B5  and  "C" 


3.  CONFIGURATION  MANAGEMENT  ORGANIZATION 

The  MDAC  AOTS  Program  Manager  (his  designee  is  the  configuration 
management  manager)  is  the  single  point  contact  to  AFHRL 
regarding  the  execution  of  the  details  and  intention  of  this 
plan. 

Configuration  Management  has  CM  responsibility  and  authority  to 
enforce  AOTS's  CM  policies  and  procedures.  CM  performs  four 
functions  in  the  AOTS  Program  Organization:  Configuration 
Identification,  Configuration  Change  Control,  Configuration 
Status  Accounting,  and  Configuration  Audits. 

Configuration  Management,  organizationally  reports  functionally 
to  the  MDAC  AOTS  Program  Manager  for  the  effective  performance  of 
the  configuration  management  functions.  CM  will  provide  the 
necessary  visibility  into  the  development  process  at  any  given 
time.  CM  will  be  the  focal  point  for  all  matters  relating  to 
configuration  change;  and  will  enforce  the  CM  policies,  practices 
and  procedures  enabling  CM  to  carry  out  this  mandate.  The 
Configuration  Manager  or  his  designee  will  administer  all 
Configuration  Control  Board  (CCB)  reviews  co-chaired  by  the  MDAC 
AOTS  Program  Manager  and  the  AFHRL/ 0L- AK  chief. 

The  AOTS  organization  charts  for  the  AOTS  program  as  it  relates 
to  configuration  control  is  shown  in  Figure  3-1. 
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AOTS  CONFIGURATION  MANAGEMENT 
ORGANIZATION 


Fig.  3-1:  AOTS  Organization  Chart 
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4.  CONFIGURATION  IDENTIFICATION 


AOTS  CM  will  use  vendors'  commercial  identification  and 
serialization,  to  the  extent  that  they  exist  for  off-the-shelf 
hardware/software.  CM  will  develop  an  internal  identification 
and  serialization  program  which  builds  on  existing  definition  and 
complies  with  the  standards  and  requirements  of  the  AOTS  contract 
and  Statement  of  Work  (SOW) . 

Configuration  identification  is  the  current  approved  or 
conditionally  approved  technical  documentation  for  a  Hardware 
Configuration  Item  (HWCI)  or  a  Computer  Program  Configuration 
Item  (CPCI)  as  set  forth  in  specifications,  drawings,  and 
associated  lists,  and  documents  referenced  therein.  This 
technical  documentation  defines  the  functional  and/or  physical 
characteristics  of  a  system,  equipment,  or  item  which  have  been 
(or  is  to  be)  achieved  in  the  AOTS  product. 

The  objective  of  configuration  identification  is  to  establish  and 
record  the  approved  technical  description  of  the  AOTS  system, 
equipment,  or  item  designated  for  configuration  management.  The 
description  will  be  the  basis  for  configuration  control,  and  will 
be  maintained  throughout  the  life  cycle  of  a  HWCI  or  CPCI, 
starting  with  the  initial  configuration  and  continuing  with 
configuration  updates  resulting  from  the  incorporation  of 
approved  changes. 

The  aggregate  of  the  documentation  which  describes  the  individual 
systems,  subsystems,  and  items  results  in  the  establishment  of 
AOTS  baselines.  5 

There  are  two  aspects  of  Configuration  Identification: 

o  Identification  of  the  configuration  item  by  its 

description  through  its  design  specifications,  test 
documentation,  operator's  manual,  and  listings. 

o  Identification  of  the  documents  by  name,  a  unique 
number,  other  identification,  and  cross-reference 
listings. 

4.1.  Baseline  Establishment 

Baselines  are  AFHRL- approved  technical  descriptions  that  provide 
the  basis  for  configuration  control  and  status  accounting.  They 
consist  of  a  configuration  identification  document  or  a  set  of 
such  documents  which  define  the  item  involved  at  a  specific  point 
in  time  of  the  AOTS  program.  Figure  4-1  illustrates  the  hardware 
and  computer  program  configuration  item  control  forms. 
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HARDWARE  AND  SOFTWARE 
CONFIGURATION  ITEM  CONTROL 

[h*R0NAR6  CONFIGURATION  ITEM  I 


SOFTWARE  CONFIGURATION  ITEM 


AOTS0C10-9 


AOTS00I0-16 


Fig.  4-1:  Baseline  Configuration  Control  Forms 


The  baseline  for  the  AOTS  prototype  system  has  been  established 
with  the  PDR  and  completion  of  Phase  I  of  the  contract.  At  that 
time,  the  preliminary  designs  and  specifications  for  the  system 
and  each  of  the  five  subsystems  was  established.  Any  changes 
henceforth  require  use  of  the  configuration  control  system. 

The  establishment  of  the  baseline  for  the  design  of  each  CPCI  is 
the  conclusion  of  the  interim  technical  review  and  CDR.  The 
actual  CPCI  source  code  will  become  baselined  prior  to  software 
system  level  testing.  At  this  point,  CPCI  baseline  description 
documentation  will  be  prepared  (CPCI  form) .  All  source  software 
CPCIs  (at  lowest  level  to  highest  level)  will  always  be  under 
Source  Code  Control  System  (SCCS) .  SCCS  is  a  software  control 
package  on  the  host  computer  system.  SCCS  will  be  the  principal 
tool  used  to  control  all  source  software  code  from  the  beginning 
of  development  through  finished  product.  SCCS  will  also  be  used 
as  the  controlling  device  for  the  subsequent  maintenance  and 
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enhancement  of  any  part  of  the  software  system. 

The  establishment  of  the  baseline  for  the  HWCIs  is  set  by  the 
actual  installation  of  equipment.  At  that  time,  all  HWCIs  will 
be  documented  in  HWCI  description  documentation  (use  of  Hardware 
Configuration  Item  form) . 

This  point  is  the  point  of  departure  for  control  of  future 
changes.  AOTS  Baselines,  plus  approved  changes  to  those 
baselines,  constitute  the  current  configuration  identification. 

Formal  baselines  will  be  established  for  Advanced  On-The-Job 
Training  System  (AOTS) : 

o  Functional 

o  Allocated 

o  Product 


4.1.1.  Functional  Configuration  Identification  (FCI) 

The  Functional  Baseline  is  a  set  of  documents  that  defines  all 
necessary  functional  (performance  requirements  of  a  CPCI) . 

The  Configuration  identification  for  this  baseline  consists  of 
the  A  System  Specification  document.  This  document  is  baselined  | 
at  the  completion  of  the  System  Level  Design  Review  and  needs  to  | 
be  established  at  not  later  than  CDR.  | 

4.1.2.  Allocated  Configuration  Identification  (ACI) 

The  configuration  identification  for  the  Allocated  Baseline 
consists  of  the  B1  Prime  Item  Specifications,  B2  Critical  Item 
Specifications  and  the  B5  Computer  Program  Configuration  Item 
Development  Specification.  These  documents  are  baselined  at  the 
completion  of  the  Preliminary  Design  Review  (PDR) . 

4.1.3.  Product  Configuration  Identification  (PCI) 

The  Product  Baseline  is  the  documentation  of  all  those  parts  and 
equipments  that  collectively  meet  the  requirements  of  the 
Functional  Baseline.  The  Product  Baseline  not  only  describes  the 
’’build  to"  or  "form  fit,"  and  functional  requirements  but  their 
associated  acceptance  test  requirements.  The  design  Product  | 
Baseline  documentation  is  established  at  CDR.  I 

The  configuration  identification  for  the  Product  Baseline 
consists  of  the  updated  Computer  Program  Product.  These 
specifications  are  baselined  at  the  completion  of  software  | 
system  testing  and  the  completion  of  the  Functional  Conf iouration  | 
Audit  (FCA)  and  Physical  Configuration  Audit  (PCA) .  I 
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4.2.  Hardware  Identification 


4.2.1.  Hardware  Identification  Method 

AOTS  will  develop  a  reference  designator  system  of  identification 
traceable  to  the  rack,  unit,  and  component  level,  and  implemented 
throughout  the  program  under  guidance  of  Appendix  IX  of  MIL-STD- 
483A.  This  reference  designator  will  track  to  the  lowest  line 
replaceable  unit  (LRU)  level,  as  designated  through  the  logistics 
support  program.  Product  identification  requirements  will  be 
specified  in  the  product  baseline  documentation  package, 
including  as  applicable: 

a.  Marking 

b.  Hardware  Part  Number 

c.  Program/Data  Names 

d.  Media  identifiers 

e.  HWCI  identifiers 

f.  Serial  Numbers 

g.  Program  Version  identifiers 

h.  Firmware  identification 

i .  Nomenclature 


Specific  identification  number  blocks  and  assignments  will  be 
developed  by  AOTS  in  conjunction  with  vendors  and  subcontractors, 
and  assigned  through  configuration  management. 

Appendix  E  contains  the  identification  schema  that  will  be  used 
for  the  prototype  AOTS  system  at  Bergstrom  AFB,  Texas. 

4.2.2.  Hardware  Configuration  Item  (HWCI) 

The  following  guidelines  will  be  used  to  identify  HWCIs  whenever 
possible  and  practical. 

o  HWCI  identifiers  will  not  exceed  seven  (7)  alphanumeric 
characters . 

o  HWCI  sub-level  identifiers  will  be  made  up  (not  to 
exceed  seven  alphanumeric  characters)  to  the  lowest 
level  inter-changeable  part  (i.e.  a  subassembly  not 
component  level) . 

o  A  hierarchy  of  designations  will  be  established  and  used 
for  each  HWCI. 
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The  h ' -irarchy  is  estabilished  and  can  be  found  in  appendix  D. 

4.2.3.  Serialization 

To  ensure  adequate  control  of  change  incorporation,  serialization 
requirements  will  be  identified  to  each  separable  Line 
Replaceable  Unit  (LRU)  level.  Existing  vendor  serial  numbers 
will  be  used  to  the  greatest  extent  possible.  When  serial  number 
identification  of  vendor-supplied  hardware  is  inadequate,  the  CM 
manager  will  ensure  the  proper  application  of  a  identification 
number. 

4.3.  Software  Configuration  Identification 

Software  change  control  procedures  will  be  implemented  before 
development  and  before  hardware  and  software  component 
integration,  as  a  means  of  ensuring  intercommunication  among  the 
engineering  elements  in  order  to  anticipate  the  impacts  of 
changes  in  one  item  upon  the  others.  As  baselines  are  developed, 
configuration  status  will  be  tracked  to  ensure  the  integrity  of 
the  baseline.  AOTS  will  develop  document  control  codes  for  all 
the  required  software  specifications,  and  a  CPCI  number  for  each 
CPCI .  Source  code  listings  will  be  used  to  establish  the 
detailed  configuration  identification  of  the  software. 

Re-identification  of  the  software,  up  to  and  including  the  CPCI 
level,  will  be  accomplished  to  track  changes  to  executable  codes 
and  data. 

4.3.1.  Computer  Program  Identification  Structure 

The  computer  program  identification  structure  shall  consist  of 
Computer  Program  Configuration  Item (si ,  Computer  Program 
Component (s) ,  and  Computer  Program  Module (s) . 

A  CPCI  will  consist  of  one  or  more  computer  porgram  components. 
For  AOTS  there  are  four  CPCIs: 

o  Evaluation  CPCI 

o  System  Support  CPCI 

o  Management  CPCI 

o  Training  Development  and  Delivery  CPCI 

A  CPC  is  a  functionally,  logically  distinct  part  of  a  CPCI.  A 
CPC  is  identified  for  purposes  of  convenience  in  specifying  and 
developing  a  CPCI  as  an  assembly  of  subordinate  elements.  A  CPC 
consists  of  a  logical  composition  of  one  or  more  subordinate  or 
interfacing  modules. 


o  Computer  Program  Component  (CPC) 
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A  CPC  is  the  actual  computer  program  in  the  form  of 
computer  instructions  stored  on  machine-readable 
media.  All  CPCs  will  be  recorded  on  the  CM  Library 
System.  The  CPC  identification  method  is  described 
below: 

Structure:  The  format  of  the  CPC  ~  re  xxxyyyz 

Where  -  XXX  =  EVL  (EVALUATION) ,  MGT  (MANAGEMENT) ,  SUP 
(SYSTEM  SUPPORT) 

Where  -  yyy  =  Numeric  code  identifying  the  package 
within  the  CPCI. 

Where  -  z  =  P  for  the  procedure  type  of  the 
package. 

o  Computer  Program  Module  (CPM) 

A  CPM  is  the  smallest  set  of  statements  able  to  be 
assembled  or  compiled. 

Structure:  The  format  of  the  CPM  IDs  are  xxxyyyz 

Where  -  xxx  =  EVL  (EVALUATION) ,  MGT  (MANAGEMENT) ,  SUP 
(SYSTEM  SUPPORT) 

Where  -  yyy  =  Numeric  code  identifying  the  package 
within  the  CPCI. 

where  -  z  =  P  for  the  procedure  type  of  the 
package . 

The  naming  conventions  for  the  CPCs  and  CPMs  are  described  in  the 
AOTS  Computer  Programming  Standards  document. 

4.4.  Document  Identification 

4.4.1.  Identification  Method 

All  documents  will  be  recorded  on  the  CM  Library  system.  The 
document  code  identification  method  is  described  below: 

Structure:  PP.  Document  ID 

Where:  PP  =  2-5  digit  alphanumeric  program  code 

Period  ( . )  =  constant  separating  program  from  document 

identifiers 

Document  ID  =  7  digit  or  less  document  identifiers. 
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This  document  ID  will  be  cross-referenced  to  the  AOTS  CDRL 
number.  A  list  of  the  applicable  documents  for  AOTS  are  listed 
in  Section  2.0. 

4.4.2.  Specification  Tree 

The  AOTS  specification  tree  is  shown  in  Figure  4-2. 
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Fig.  4-2:  AOTS  Specification  Tree 
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4.5.  Program  Release  Identification 


A  Version  Description  Document  (VDD)  will  be  prepared  at  the  time 
of  the  release  of  the  product  baseline. 

4.6.  Configuration  Management  Library 

A  library  is  maintained  for  both  documents  and  software.  A 
master  of  the  current  version  of  each  baseline  is  maintained 
along  with  an  audit  trail  to  all  changes.  See  Section  5.3 

5.  CONFIGURATION  CONTROL 

Configuration  Control  is  the  systematic  and  coordinated 
incorporation  of  approved  changes  to  the  existing  internal  and 
external  baselines.  This  control  assures  that  baselines  are 
properly  maintained. 

The  objective  of  configuration  control  is  to  define,  document, 
and  expedite  necessary  changes  to  the  progressively  established 
baseline  configurations  under  guidance  of  DoD-STD-480A,  while 
preventing  changes  that  are  not  authorized  or  beneficial. 

The  functional  baseline  defined  by  the  A  System  Specification 
establishes  the  initial  identification  of  the  AOTS  System.  This 
identification  process  will  be  expanded  throughout  the 
development  phase  as  various  reviews  approve  identification 
documents  until  the  Functional  Configuration  Audit  (FCA) ,  when 
the  documents  will  become  part  of  the  approved  identification  as 
defined  in  Section  4.0,  Configuration  Identification. 

All  changes  proposed  to  the  approved  configuration  identification 
shall  be  reviewed  by  the  AOTS  Configuration  Control  Board. 

An  overview  of  the  AOTS  Configuration  Change  Control  System  is 
shown  in  Figure  5-1. 

The  configuration  control  system  is  allowed  to  handle  expeditated 
changes.  Expeditated  changes  are  those  changes  that  are  required 
on  an  immediate  bases  in  order  to  correct  "downing"  events. 
Downing  events  are  those  which  have  a  significant  impact  to 
normal  operations.  When  these  events  occur,  the  configuration 
manager  is  authorized  to  expeditate  a  change  through  the  system 
and  call  an  emergency  meeting  of  the  configuration  control  board 
to  handle  the  matter.  During  these  events,  normal  procedures  can 
be  bypassed  in  order  to  restore  the  system.  However,  all 
paperwork  associated  with  a  change  must  be  processed  at  a  later 
time  so  that  a  full  history  of  the  change  is  provided. 

where  expeditated  change  handling  requires  deviation  from  this 
plan,  the  CM  manager,  with  approval  from  the  CCB  chairmen,  may 
institute  special  procedures. 
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5.1.  Configuration  Control  Administration 

5.1.1.  AOTS  Configuration  Management  Group 

AOTS  Configuration  Management  group  is  responsible  for  performing 
all  CM  functions.  CM  is  also  responsible  for  coordinating  the 
Configuration  Control  Board  (CCB)  and  serves  as  the  administrator 
of  that  body. 

5.1.2.  AOTS  Configuration  Control  Board  (CCB) 

A  AOTS  Configuration  Control  Board  (CCB)  will  be  established  at 
Bergstrom  AFB  with  the  authority  to  process  both  hardware  and 
software  changes.  The  AOTS  CCB  will  be  convened  as  required  to 
analyze  each  proposed  change,  deviation,  or  waiver  relative  to 
the  stated  problem  and  to  determine  the  action  to  be  taken. 

The  AOTS  CCB  membership  will  consist  of  representatives  from  MDAC 
and  AFHRL  personnel.  Each  member  will  represent  his  respective 
organization's  functions  and  will  present  its  position. 
However,  membership  may  vary  at  the  discretion  of  the  Chairmen, 
depending  on  the  nature  of  the  change. 

The  AOTS  CCB  will  be  co-chaired  by  the  AFHRL  chief  and  the  AOTS 
Program  Manager  or  their  designee  and  will  be  recorded  and 
tracked  by  Configuration  Management  (CM)  (see  Section  7.1).  It 
will  be  a  non-voting  board  with  the  Co-Chairmen  making  the  final 
decisions  on  all  changes. 

An  agenda  for  each  proposed  change,  with  available  documentation 
will  be  provided  to  the  CCB  by  CM  in  advance  of  each  meeting,  to 
aid  the  membership  in  establishing  their  recommendations 
regarding  the  total  impact  prior  to  disposition  of  each  change. 
The  CCB  is  responsible  for  judging  the  necessity  of  each  proposed 
change  by  evaluating  its  operational,  technical,  and  cost 
effectiveness. 

5.2.  Change  Processing  (AOTS  Configuration  Control  System  Flow) 
5.2.1.  Source  of  Changes 

Sources  of  external  and  internal  changes  are: 

o  Manufacturers  Hardware  Changes 
o  Maintenance  Action 

o  Engineering  Change  Requests 

o  Test/Problem  Reports 

o  User  Recommended  Changes 

o  Operating  System/Utility  software  change 
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Figure  5-2  represents  the  use  of  configuration  control  forms 
through  out  the  configuration  management  process.  These  forms 
are  contained  in  Appendix  D  to  this  document. 

5. 2. 1.1.  Manufacturers  Hardware  Change 

When  notification  of  hardware  change  is  received  from  an 
equipment  manufacturer  it  is  sent  immediately  to  the  CM  manager. 

5. 2. 1.2.  Maintenance  Action 

When  a  change  in  maintenance  operation  is  desired  an  AOTS 
Maintenance  Action  Report  Form  is  completed  and  forwarded  to  the 
CM  Manager.  (See  Appendix  D) 

5 . 2 . 1 . 3 .  Engineering  Change  Requests 

Request  for  Software  or  Hardware  changes  are  to  be  written  on 
an  Engineering  Change  Proposal  (ECP) .  Both  forms  follow  the  same 
process  and  are  sent  to  the  CM  manager  for  logging  and 
disposition. 

5. 2. 1.4.  Test/Problem  Report 

Discrepancies  between  baseline  software  operation  and 
corresponding  software  documentation  are  to  be  recorded  on  a 
Software  Trouble  Report  and  forwarded  to  the  CM  manager  for 
logging  and  disposition.  (See  Appendix  D) 

5. 2. 1.5.  User  Recommended  Changes 

Changes  requested  by  users  must  use  the  Engineering  Change 
Proposal  Form  and  forwarded  to  the  CM  manager.  (See  MIL-STD-480A 
and  MIL-STD-481A.) 

5. 2. 1.6.  Operating  System/Utility  Software  Changes 

Changes  of  this  nature  when  reported  by  the  manufacturer  on  a 
Manufacturer's  Notice  are  to  be  forwarded  directly  to  the  CM 
manager.  The  CM  manager  will  prepare  an  ECP  for  these  types  of 
changes . 
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Figure  5-2:  Configuration  Control  Forma  Used  Throughout 
Configuration  Management  System  for  AOTS. 
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5.2.2.  CM  Control 


The  CM  manager  or  his  designate  performs  the  following  function 
on  documents  received: 

o  Log  Control  Number 

o  Enter  date  into  CM  Audit  Tracking  System 
o  Assign  Classification 

o  Determine  Routing 

o  Prepare  AOTS  Configuration  Control  Form 

o  Initiate  AOTS  Estimate  Work  Sheet  Summary  Form 

o  Initiate  Advance  Change/Study  Notice  Form  (if 

applicable) . 

All  paper  work  associated  with  any  change  will  always  accumulate. 
No  step  is  authorized  to  remove  any  paper  work  from  a  change. 
Any  additional  data  can  be  added  as  documentation  to  a  change. 

5 . 2 . 2 . 1 .  Log  Control  Number 

The  CM  manager  assigns  a  consecutive  number  to  each  applicable 
document  received. 

5. 2. 2. 2.  Enter  data  into  CM  Audit  Tracking  System 

Pertinent  data,  now  tied  to  a  unique  Control  Number  is  entered 
into  the  Audit  Tracking  System.  The  CM  manager  will  institute  an 
automatic  CM  tracking  system  utilizing  a  Zenith  Z-248  PC  using 
a  data  base  system. 

5. 2. 2. 3.  Assign  Classification 

The  CM  manager  assigns  a  change  classification  using  MIL-STD-480A 
as  a  guide.  Classifications  are  defined  as  follows: 

o  Class  1  change.  Any  change  affecting  cost,  schedule, 
performance  or  the  contract  technical  baseline. 

o  Class  2  change.  Any  change  to  correct  errors  (bugs)  in 
computer  programs  or  documentation  which  does  not  affect 
the  "form,  fit,  or  function”  of  a  baseline.  Class  2 
changes  are  also  defined  as  those  which  correct  errors 
in  approved  baselines. 

If  the  Configuration  Manager  can  not  make  the  determination  of 
the  classification,  the  Configuration  Control  Board  (CCB)  will 
make  the  decision.  The  CCB  has  the  authority  to  make  the  final 
decision  concerning  change  classification. 
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5. 2. 2. 4.  Determine  Routing 

The  CM  manager  routes  the  appropriate  forms,  per  this  plan,  that 
are  initiated  under  his  control,  including  those  described  below. 

5 . 2 . 2 . 5 .  Prepare  AOTS  Configuration  Control  Form 

The  CM  manager  completes  the  AOTS  Configuration  Control  Form. 
(See  Appendix  D.)  The  Configuration  Control  Form  (CCF)  will  be 
used  to  provide  overall  summary  of  a  change  and  is  used  to  show 
approval/disapproval  or  other  routing  for  a  change.  This  form  is 
the  "top"  form  for  the  configuration  management  process.  For 
Recommended  Class  1  changes,  which  the  CCB  does  not  have 
authority  to  authorized  but  only  advise,  will  require  a 
Engineering  Change  Proposal  and  a  Contract  Change  Proposal  to  be 
prepared  by  the  AOTS  configuration  management. 

5. 2. 2. 6.  Initiate  AOTS  Estimate  Work  Sheet  Summary  Form 

The  CM  manager  initiates  this  form  based  on  change  classification 
and  determines  proper  routing.  This  form  is  used  to  accumulate 
all  estimates  (manpower  and  schedule)  of  a  proposed  change.  This 
will  be  the  third  level  form  (top  form  being  the  CCF  followed  by 
the  Risk  Analysis  Worksheet  Summary  Form) . 

5. 2. 2. 7.  Initiate  Advance  Change/Study  Notice  Form 

If  deemed  appropriate  by  the  CM  manager  based  on  the  magnitude  of 
the  change  requested  this  form  is  generated.  (See  MIL-STD-483A. ) 

5. 2. 2. 8.  AOTS  Estimate  Worksheet  Form 

An  AOTS  Estimate  Worksheet  form  is  provided  to  each  group  that 
the  configuration  manager  determines  that  may  be  affected  by  the 
proposed  change  or  change  action.  The  form  is  used  by  the  group 
to  report  back  the  impact  on  the  change  on  their  group. 

5. 2. 2. 9.  Risk  Analysis  Worksheet  Form 

The  risk  of  any  change  must  be  analyzed  and  a  project  risk 
statment  made  by  the  program  management  from  both  the  Air  Force 
and  MDAC. 


5.2.2.10.  Risk  Analysis  Worksheet  Summary  Form 

The  configuration  manager  will  take  the  data  from  the  Risk 
Analysis  Worksheet  form  and  summarize  the  data  from  both  the  Air 
Force  and  MDAC  onto  the  summary  form.  This  form  will  be  the 
second  highest  form  (below  the  Configuration  Control  Form) . 

5.2.3.  Evaluation  Phase 

Upon  completion  of  the  appropriate  documents  by  the  CM  manager 
the  evaluation  phase  begins.  During  this  phase  the  following 
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tasks  are  achieved: 

o  Prepare  Engineering  and  Subcontract  Notification  for 
Study/Estimate 

o  Define  Requirements  for  change  and  provide  estimates 

o  Log  changes  into  Audit  Tracking  System  (Configuration 
Status  Accounting  System) 

o  Prepare  Estimate  and  Risk  Analysis  Summary  Forms 

o  Update  the  Configuration  Control  Form  with  summary 
data  from  the  Estimate  and  Risk  Analysis  Summary 
Forms 

o  Gather  input  from  other  organizations  as  required 
o  Use  checklist  to  determine  classification. 

5.2. 3.1.  Engineering  and  Subcontract  Notification 

These  notifications  are  prepared  and  distributed  to  the 
appropriate  parties  by  Configuration  Management.  Their  purpose 
is  to  solicit  estimates/ recommendations  on  the  proposed  change. 

5. 2. 3. 2.  Define  Requirements  for  Change  and  Provide  Estimate 

In  the  preceding  phase  the  CM  manager  routed  correspondence  to 
appropriate  recipients  requesting  data.  In  the  evaluation  phase 
these  recipients  are  to  supply  the  requested  study/estimates/data. 

5. 2. 3. 3.  Log  Changes  Into  Audit  Tracking  System  (Configuration  Status 
Accounting  System) 

The  CM  manager  or  his  designate  is  responsible  for  logging  the 
progress  of  all  change  documents  into  the  tracking  system. 

5. 2. 3. 4.  Prepare  AOTS  Estimate  Work  Sheet  Summary 

It  is  the  responsibility  of  the  CM  manager  to  prepare  an  AOTS 
Estimate  Work  Sheet  Summary  Form  from  the  studies/estimates/ data 
provided.  (See  Appendix  D.) 

5. 2. 3. 5.  Gather  Input  From  Other  Organizations  As  Required 

The  CM  manager  is  responsible  for  contacting  whomever  he  deems 
necessary  to  prepare  adequate  documentation  for  the  CCB. 

5. 2. 3. 6.  Prepare  Checklist 

The  CM  manager  prepares  a  checklist  to  assure  that  all  required 
data  is  available.  An  AOTS  Subsystem  Worksheet  Form  (See 
Appendix  D.)  is  to  be  completed  by  the  manager  of  each  affected 
subsystem.  Areas  which  may  be  affected  include  Engineering, 
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Quality  Assurance,  Risk  Analysis,  Human  Factors,  Safety  and 
Subcontractors.  Typically  the  following  data  will  be  available 
for  the  CCB: 


-  Impact  Analysis,  Costs  etc. 

Estimates 

Schedules 

Affected  HWCIs  and  CPCIs 
Affected  Documentation 

-  Affected  Specifications 
Other  data  as  required 

5.2.4.  Configuration  Control  Board  (CCB) 

The  CCB  is  responsible  for  the  following  functions: 

o  Review  and  Classify  Change (s) 

o  Evaluate  Cost  Impacts,  Schedule,  etc. 

o  Approve/ Disapprove  Change (s)  (Class  2  approval, 

advise  approval  of  Class  1  changes) . 

o  Routing 

o  Assuring  that  the  Tracking/Status  system  is  updated  by 
the  CM. 


5 . 2 . 4 . 1 .  Disapproved  changes 

When  a  change  is  disapproved  by  the  CCB  the  following  actions 
take  place: 

o  The  change  is  closed  out  and  the  CM  manager  updates  the 
tracking  system. 

o  All  pertinent  data  is  archived. 

o  The  originator  of  the  change  request  is  notified  (if 
applicable) . 

o  Any  other  individuals,  groups,  or  organizations  who  have 
a  need  to  know  are  notified. 

If  a  Class  1  change  is  disapproved  by  the  Air  Force  Contracting 
Officer,  the  disapproved  change  is  handle  in  the  same  manner. 

5 . 2 . 4 . 2 .  Approved  Changes 


Version  1.01 


Page  23 


Approved  In-Scope  changes  proceed  directly  to  the  CM  Planning 
Phase. 


5.2.5.  Approved  Out-of-Scope  Changes 

When  an  out  of  scope  change  is  approved  the  CM  manager  completes 
an  Engineering  Change  Proposal  and  updates  the  Audit  Tracking 
System.  The  ECP  is  forwarded  to  the  Air  Force  Contracting 
officer  for  resolution.  Should  the  Air  Force  disapprove  the 
change  it  is  closed  out  and  follows  the  same  route  of  an  in-scope 
disapproved  change.  (Refer  to  5.2.4. 1)  Should  the  Air  Force 
approve  the  change  they  contact  the  MDAC  Contracting  Officer  and 
provide  authorization  to  proceed.  The  change  now  enters  the  CM 
Planning  Phase. 

5.2.6.  CM  Planning  Phase 

When  the  CM  manager  is  notified  that  either  an  in-scope  or  out- 
of-scope  change  has  been  approved  he  updates  the  tracking  system 
accordingly.  He  also  assures  that  the  following  actions  take 
place: 

o  A  schedule  for  release  is  established. 

o  The  implementation  and  testing  group  is  notified  that 
the  change  is  approved  and  instructed  to  proceed. 

o  Individuals,  groups,  and  other  organizations  who  have 

a  need  to  know  are  notified  that  the  change  is  approved. 

o  QA  is  notified. 

o  The  Audit  Tracking  System  (Configuration  Status 

Accounting  System)  is  updated. 

5.2.7.  Implementation  and  Testing 

During  this  phase  the  following  functions  are  accomplished: 

o  Hardware  Changes  are  engineered  (including  development 
of  a  modification  kit) 

o  Software  Changes  are  engineered 

o  Unit  and  System  level  tests 

o  Specifications  are  updated. 

o  Documentation  is  updated. 

o  Other  documentation  (as  affected)  is  updated. 

o  QA  checks  for  specification  compliance  and  assures 
conformity  to  standards. 
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o  QA  assures  that  system  meets  functional  requirements. 

o  Beta  test  release  data  is  prepared. 

o  Internal  Tracking  System  is  updated. 

o  Recycle  any  change  as  a  result  of  Beta  testing  where 
the  problem  has  not  been  fully  corrected. 

Upon  completion  of  the  above,  the  change  is  closed  out  by  the 
affected  groups.  The  CM  tracking  system  is  updated  upon 
completion  of  this  phase  of  work. 

5.2.8.  Beta  Testing 

Beta  Testing  is  applicable  for  hardware  and  software  changes. 
Beta  testing  will  varify  the  change  is  working  and  no  additional 
problems  have  been  caused  as  a  result  of  this  change.  The  Beta 
Test  group  makes  the  decision  when  a  new  version  of  software  or 
hardware  change  is  to  be  released  to  users.  The  results  of  Beta 
Testing  may  initiate  a  new  change  which  starts  another  cycle. 
Refer  to  Section  5.2.1,  Source  of  Changes.  Once  Beta  Testing  is 
completed,  the  software  and  hardware  enters  the  Release  phase. 

5.2.9.  Release 

Updated  software  is  copied  to  the  appropriate  media  and 
distributed  along  with  updated  documentation.  At  this  point  the 
change  is  closed  and  the  Tracking  System  is  updated. 
Documentation  is  to  include  installation  instructions  for  the 
user. 

Hardware  changes  are  also  released  as  kits  to  the  user.  A  kit 
will  contain  all  necessary  parts  and  instructions  for  installing 
the  modification.  Release  is  responsible  for  obtaining  necessary 
parts  for  the  kit. 

Release  is  also  responsible  for  printing  all  necessary 
documentation  changes  and  preparing  the  release  of  these  to  the 
user. 

Full  installation  instructions  will  be  prepared  for  any  change 
and  distributed  from  the  release  group. 

Release  group,  upon  actual  release  of  a  change,  will  update  the 
baseline  control  documents  for  the  appropriate  HWCI  or  CPCI. 

5.2.10.  User 

The  user  is  responsible  for  installation  of  updated  software  and 
hardware  upon  receipt  of  same.  Any  difficulties  encountered  in 
installing  updated  software  or  a  hardware  modification  kit  is  to 
be  resolved  with  the  group  in  charge  of  release. 

The  release  group  can,  in  turn,  consult  engineering  for  help  in 
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resolving  installation  problems. 

The  user  will  complete  and  return  to  CM,  the  installation 
completed  form  (see  Appendix  C)  .  CM,  upon  receipt  of  the 
installation  completed,  will  update  the  master  unit  files  to 
indicate  change  has  been  installed.  If  changes  are  not  installed 
in  a  resonable  amount  of  time,  the  CM  system  will  notify  the  user 
that  the  change  must  be  installed  in  order  to  maintain 
configuration  control  over  the  system.  Necessary  actions  will  be 
taken  to  alert  appropriate  command  levels  to  ensure  installation 
of  deliquent  changes. 

5.3.  Data  Management 

The  Configuration  Management  Library  will  be  AOTS's  vehicle  for 
data  management.  This  library  will  be  the  medium  to  assure 
complete  technical,  administrative,  and  physical  control  of 
changes  to  software  documents  and  software  media.  Configuration 
Management  will  be  responsible  for  logging  change  requests  as 
they  are  received  for  processing  and  will  maintain  the  status  of 
each  change  until  it  is  completed.  The  data  management  control 
system  will  ensure  that: 

o  All  released  software  and  hardware  elements  are  entered 
into  the  library. 

o  The  different  program  versions  in  the  library  are 
identified,  controlled,  and  documented. 

o  Back-ups  for  all  masters  are  stored  in  an  approved 
separate  location. 

o  No  unauthorized  modifications  are  made  to  the  source  or 
object  programs  or  to  documentation. 

o  Procedures  are  enforced  for  controlling  the  flow  of  media 
and  listings  into  and  out  of  the  library. 

o  Access  to  the  library  is  limited  to  authorized  personnel 
only. 

5.4.  Deviation  or  Waiver 

Hardware  or  Software  shall  not  be  delivered  incorporating  a  known 
departure  from  documentation  unless  a  request  for  deviation  or 
waiver  memo  has  been  processed  and  approved  in  accordance  with 
the  requirements  of  this  plan  or  unless  otherwise  permitted  by 
contractually  authorized  personnel.  Request  for  deviation  on 
waiver  shall  be  submitted  in  memo  form  to  the  AFHRL. 

Definitions  of  deviation  and  waiver  are  given  below: 

o  Deviation 

A  deviation  is  the  authorization  to  depart  from  a 
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particular  requirement  of  a  specification,  drawing,  or 
other  document,  for  a  specific  number  of  units  or  a 
specific  period  of  time. 

o  Waiver 

A  waiver  is  the  authorization  to  accept  an  item  which, 
during  production  or  after  having  been  submitted  for 
acceptance,  is  found  to  depart  from  specified  requirements, 
but  which  is  nevertheless  considered  suitable  for  use. 

Standard  DoD  forms,  as  described  in  MIL-STD-480A,  will  be  used 
for  these  functions. 

6.  CONFIGURATION  AUTHENTICATION 

Reconciliation  and  control  of  software  and  documentation  are 
controlled  according  to  the  process  outlined  in  Section  5.  The 
controls  make  use  of  the  various  CM  status  accounting  reports  and 
CM  identification  lists.  Control  points  are  set  up  at  various 
stages  along  the  change  processing  system,  to  ensure  that 
established  procedures  and  approved  controls  are  being  followed. 

o  Documentation 

CM  receives  and  logs  copies  of  all  documents  before 
they  are  mailed  for  external  distribution.  Archives 
are  kept  under  a  secured  environment. 


During  software  implementation  testing,  CM  will  control 
the  movement  of  files  from  the  Test  Environment  to  the 
Distribution  Environment.  Only  authorized  changes  will 
be  permitted. 

o  Hardware 

CM  and  QA  will  check  and  verify  the  configuration  before 
it  is  released  to  production. 

7.  CONFIGURATION  STATUS  ACCOUNTING 

AOTS  will  initiate  a  configuration  indexing  and  accounting  system 
with  the  identification  and  recording  of  each  item's  approved 
configuration  and  then  continuously  track  them  to  ensure  that  all 
relevant  conditions  of  each  approved  change  are  observed  and 
recorded.  Configuration  accounting  will  be  used  to  maintain 
systematic  records  of  configuration  items  and  actions  affecting 
configuration  items,  and  also  to  generate  reports  for  the  Program 
Manager.  To  perform  the  status  accounting  function,  CM  systems 
will  be  performed  on  a  PC  using  a  DBMS  system. 

Continuous  management  of  established  baselines  will  be  performed 
under  guidance  of  MIL-STD-483,  to  maintain  the  status  on  all 
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proposed  and  approved  changes,  to  both  AOTS  and  vendor 
software/hardware. 

The  kinds  of  status  accounting  to  be  performed  by  Configuration 
Management  are  listed  below. 

7.1.  Program  Transaction  Log 

This  automated  reporting  system  tracks  all  correspondence  between 
MOAC  and  AFHRL. 

7.2.  CCB  Status  Accounting 

This  reporting  system  includes  CCB  agendas  and  minutes,  and 
change  status  reporting.  This  system  also  generates  and  tracks 
action  items  from  the  CCB. 

7.3.  Software  Problem  Report  (SPR)  Status  Accounting 

This  reporting  system  will  track  the  status  of  each  SPR  from 
start  to  completion. 

7.4.  CM  Library  Status  Accounting 

Lists  of  all  AOTS  documentation,  their  current  versions  and 
history  of  changes  are  kept.  Distribution  control  lists  are  also 
maintained. 

7.5.  System  Allocation  Document 

A  System  Allocation  Document  will  be  kept  for  both  software  and 
hardware  configuration  for  the  system  site  that  will  receive  the 
deliverables : 

o  .  Bergstrom  AFB 

7.6.  Release  Processing  Status 

o  Release  Work  Log 

This  log  documents  the  history  of  each  release, 
o  CM  Release  Status  Report 

This  report  gives  the  status  of  all  releases  in  process  and 
completed  releases. 

7.7.  Deviation  and  Waiver  Reporting 

The  CM  Deviation/Waiver  Log  documents  the  history  of  each 
Deviation  or  Waiver  request. 
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8.  INTERFACE  MANAGEMENT 


When  Class  1  changes  as  described  in  Section  5.0  are  proposed 
MDAC  AOTS  Program  Manager  and  AFHRL/OL-AK  will  accomplish  the 
necessary  coordination  to  develop  all  documentation  required  to 
support  a  Government  decision  on  the  change. 

Each  lead  engineer  for  or  AOTS  subsystem  manager  will  be  the 
responsible  individual  to  ensure  that  the  interfaces  with/to 
other  AOTS  subsystems  are  fully  understood.  This  analysis  will 
be  included  in  the  impact  response  to  any  change.  Any  subsystem 
that  has  an  external  interface  to  another  Air  Force  system  will 
also  be  determined  and  reported  on  in  the  impact  statement. 

9.  CONFIGURATION  AUDITS 

9.1.  Introduction 

AOTS  project  will  conduct  Functional  Configuration  Audits  (FCA) 
and  Physical  Configuration  Audits  (PCA)  individually  for  the 
equipment  CIs  and  the  computer  program  CPCIs  with  a  phased 
schedule.  These  audits  will  be  conducted  under  the  guidance  of 
MIL-STD-1521A. 

An  audit  plan  will  be  prepared  by  the  AOTS  configuration 
management  and  approved  by  AFHRL/OL-AK  30  days  prior  to  the 
audit.  AOTS  configuration  managment  will  coordinate  the  schedule 
and  agenda  for  each  audit,  ensure  appropriate  participation  by 
our  vendors  and  our  subcontractors,  and  record  and  distribute  the 
findings. 

AOTS  project  will  also  performs  software  development  reviews 
during  the  software  life  cycle. 

9.2.  Functional  Configuration  Audit  (FCA) 

The  FCA  will  be  a  formal  audit  of  a  HWCI/CPCI  to  verify  that  the 
actual  performance  complies  with  the  requirements  of  its 
development  specification.  The  successful  completion  of  the  FCA 
will  be  a  prerequisite  leading  to  scheduling  a  PCA.  The  FCA  will 
be  conducted  under  guidance  of  MIL-STD-1521A,  Appendix  E.  This 
audit  normally  will  be  conducted  following  completion  of  the 
formal  Testing  of  a  HWCI/CPCI.  The  FCA  for  a  complex  HWCI/CPCI 
may,  when  so  specified  by  the  Customer,  be  performed  on  an 
incremental  basis  during  the  development  of  the  HWCI/CPCI  and 
culminate  with  the  completion  of  HWCI/CPCI  Testing.  The 
Contractor,  in  conducting  the  audit,  will  provide  the  necessary 
materials  and  data  to  enable  the  Customer  to  assure  the  following: 

o  The  testing  of  the  specified  HWCI/CPCI  was  accomplished 
with  approved  test  procedures  and  validated  data  are 
sufficient  to  assure  that  HWCI/CPCI  performance  is  in 
compliance  with  the  requirements  of  the  Development 
Specification; 
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o  Any  differences  between  test  data  and  specification 
requirements  have  been  resolved  and  recorded  in  the 
minutes  of  the  FCA; 

o  Acknowledgment  has  been  made  a  matter  of  record  for 

partial  accomplishment  of  the  FCA  for  those  HWCls/CPCIs 
whose  acceptance  is  contingent  upon  completion  of 
integrated  systems  testing. 

Following  receipt  of  the  FCA  minutes,  the  AFHRL  will  establish 
the  adequacy  of  the  AOTS's  review  performance  through  formal 
Contracting  Officer  notification. 


9.3.  Physical  Configuration  Audit  (PCA) 

The  PCA  is  the  formal  examination  of  the  as-built  version  of  a 
HWCI/CPCI  in  comparison  with  its  current  technical  documentation. 
For  hardware  CIs,  its  purposes  are  to  assure  that  the  equipment 
is  fabricated  in  accordance  with  the  current  technical 
documentation  and  that  the  documentation  is  complete  and  suitable 
for  use  in  production,  for  accepting  subsequent  production  units, 
and  for  support  of  operations,  maintenance  and  logistics.  For  a 
CPCI ,  the  principal  purpose  is  to  verify  that  the  product 
specification  is  a  complete  and  accurate  technical  description  of 
the  CPCI  being  delivered.  The  "as-built"  configuration  of  the  Cl 
will  be  verified  by  the  results  of  testing  performed  prior  to 
PCA.  Successful  completion  of  the  PCA  will  establish  the  product 
specifications  as  the  PCI  for  subsequent  configuration  control  at 
the  Product  Baseline  level.  Upon  successful  completion  of  the 
PCA,  Product  Baseline  will  be  established  and  all  subsequent 
changes  to  the  CI/CPCI  will  be  processed  against  the  Product 
Specification. 

The  PCA  will  be  conducted  after  successful  completion  of  the 
CI/CPCI  SLT&E  and  prior  to  AFHRL  Acceptance  Tests  and  in  general 
guidance  of  MIL-STD-1521A,  Appendix  F.  In  performing  the  PCA, 
AOTS  will  provide  the  materials  and  data  necessary  to  enable  the 
AFHRL  to  ascertain  the  following: 

o  The  as-built  configuration  of  the  specified  CI/CPCI 
correlates  with  the  "As-Designed"  record  plus  the 
"As-Planned"  record  for  the  item  being  audited  or  that 
all  differences  have  been  reconciled; 

o  The  acceptance  testing  requirements  in  the  Product 

Specification  for  a  CI/CPCI  are  adequate  for  acceptance 
by  the  Quality  Assurance  group. 

o  Traceability  is  established  to  the  Functional 
Configuration  Audit  (FCA)  such  that  additional 
functional  testing  is  shown  to  have  been  accomplished. 
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9.4.  Software  Development  Reviews 


AOTS  Program  Management  will  conduct  the  following  software 
development  reviews  during  development: 

o  Preliminary  Design  Review  (PDR) 

o  Critical  Design  Review  (CDR) 

10.  SUBCONTRACTOR/VENDOR  CONTROL 

AOTS  is  responsible  for  assuring  that  all  software,  documentation 
and  programming  materials  procured  from  subcontractors  conform  to 
the  prime  AOTS  contract  requirements.  Therefore,  this  plan  shall 
be  invoked  on  all  commercial/  off-the-shelf  subcontractors. 

11.  MAJOR  MILESTONES 

11.1.  Configuration  Management  Program  Phasing 

To  ensure  the  consistency  of  key  Configuration  Management 
activities  so  that  the  overall  program  schedule  can  be  attained, 
an  AOTS  Engineering  schedule  is  prepared  and  illustrates  the 
major  milestone  and  detail  program  schedules  for  each  subsystem. 
Configuration  Management  activities  are  integral  with  the  program 
objectives  and  are  reflected  in  the  scheduling  of  CM  events 
consistent  with  the  AOTS  Program  requirements.  The  establishment 
of  baseline  identifications  are  timed  to  meet  these  requirements. 
Configuration  audits  and  reviews  are  scheduled  to  be  consistent 
with  AOTS  engineering  reviews  and  individual  configuration  item 
development  schedules. 

11.2.  Configuration  Management  Major  Milestones 

The  major  milestones  for  Configuration  Management  are  based  on 
the  phasing  of  program  events  that  establish  related  milestones, 
or  that  identify  the  significant  baselines  planned  for  the  AOTS 
Program.  Major  milestones  are  indicated  in  Block  12  and  13  of 
the  CDRL  and  are  illustrated  in  the  Work  Breakdown  Schedule 
(WBS) . 

The  AOTS  Master  Schedule  will  be  used  to  indicate  major  | 
Configuration/Program  Management  milestones.  This  schedule  will  j 
be  used  for  Configuration  Management  Planning  but  is  not  required  | 
to  be  a  part  of  this  plan.  I 
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APPENDIX  A  -  LIST  OF  ACRONYMS,  ABREV.,  AND  INITIALS 


ITEM 


DESCRIPTION 


AFHRL 

AOTS 

CBTS 

CCB 

CCF 

CDR 

CLIN 

CDRL 

CM 

CMP 

CPC 

CPCI 

CPDS 

CPTR 

CSDM 

CSOM 

CSTP 

DBDD 

DID 

DOD 

DODISS 

ECP 

FCA 

FSED 

FSM 

GFE 

GFS 

HOL 

HWCI 

IDD 

IRS 

MTP 

PCA 

PDR 

PR 

PROM 

QAP 

QAR 

RFP 

ROM 

SCP 

SCR 

SDF 


Air  Force  Human  Resources  Laboratory 
Advanced  On-The-Job  Training  System 
Computer  Based  Training  Systems 
Configuration  Control  Board 
Configuration  Control  Form 
Critical  Design  Review 
Contract  Line  Item  Number 
Contract  Data  Requirements  List 
Configuration  Management 
Configuration  Management  Plan 
Computer  Program  Component 
Computer  Program  Configuration  Item 
Computer  Program  Development  Spec 
Computer  Program  Test  Report 
Computer  System  Diagnostic  Manual 
Computer  System  Operator's  Manual 
Computer  Software  Test  Plan 
Data  Base  Design  Document 
Data  Item  Description 
Department  of  Defense 
Department  of  Defense  Index  of 
Specifications  and  Standards 
Engineering  Change  Proposal 
Functional  Configuration  Audit 
Full  Scale  Engineering  Development 
Firmware  Support  Manual 
Government  Furnished  Equipment 
Government  Furnished  Software 
Higher  Order  Language 
Hardware  Configuration  Item 
Interface  Design  Document 
Interface  Requirements  Specification 
Master  Test  Plan/Program  Test  Plan 
Physical  Configuration  Audit 
Preliminary  Design  Review 
Problem  Report 

Programmable  Read-Only  Memory 
Quality  Assurance  Plan 
Quality  Assessment  Report 
Request  for  Proposal 
Read-Only  Memory 
Software  Change  Proposal 
Specification  Change  Notice 
Software  Development  File 


Version  1.01 


Page  33 


APPENDIX  A  -  LIST  OF  ACRONYMS,  ABREV. ,  AND  INITIALS  (continued) 


ITEM 


DESCRIPTION 


SDP 

SDR 

SDRL 

SEMP 

SOW 

SPM 

SPR 

SPS 

SRS 

STR 

SUM 

VDD 

WBS 


Software  Development  Plan 
Software  Discrepancy  Report 
Seller  Data  Requirements  List 
Software  Engineering  Management  Plan 
Statement  of  Work 
Software  Programmer's  Manual 
Software  Preliminary  Design  Review 
Software  Product  Specification 
Software  Requirements  Specification 
Software  Trouble  Report 
Software  System  User's  Manual 
Version  Description  Document 
Work  Breakdown  Structure 
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SUSJCCT  CONFIGURATION  MANAGEMENT,  DEPARTMENT  OF 
DEFENSE  APPLICATIONS 


pacc-L-  or— § _ 

oats  8  Dec  69 
wpcdkoo  New  CP 


A.  SUMMARY: 

1.  Con figuration  Management  applies 
to  all  Configuration  Items  procured 
fro*  MCA1R  by  Department  of  Defense. 
The  application  of  Configuration 
Management  will  be  carefully  tai¬ 
lored  to  be  consistent  vith  the 
quantity,  site,  scope,  stage  of 
life  cycle,  nature  and  complexity 
of  the  Configuration  Iteas  involved 
and  the  appropriate  contract  re¬ 
quirements. 

B.  APPLICABLE  TO: 

Customer  Contracts  Division 
Engineering  Divisions 
Manufacturing  Division 
Material  Division 
Product  Support  Division 
Quality  Assurance  Division 

C.  DEFINITIONS: 

1.  Baselines:  Customer  approved  tech¬ 
nical  descriptions  fora  the  base¬ 
lines  of  configuration  management 
(CM)  and  provide  the  basis  for  con¬ 
figuration  control  and  status 
accounting. 

a.  Functional  Baseline:  Documented 
by  a  system  description  (per¬ 
formance  specification)  which 
describes : 

(1)  all  necessary  functional 
characteristics , 

(2)  interface  characteristics 
of  the  system  vith  asso¬ 
ciated  systems  or  items, 

(3)  tests  required  to  demon¬ 
strate  achievement  of  spec¬ 
ified  functional  character¬ 
istics,  and 


(1)  design  constraints  such  as 
Uniting  envelope  dimen¬ 
sions,  component  standardi¬ 
sation,  use  of  inventory 
items  and  Integrated  logis¬ 
tics  support  policies. 

NOTE:  For  systems  to  be 
defined  for  development 
under  contract  at  custoaer 
expense,  this  baseline  is 
established  by  custoaer 
issuance  of  a  system  speci¬ 
fication  following  approval 
to  initiate  engineering  or 
operational  development. 

b.  Allocated  Baseline:  Established 
to  govern  the  development  of 
constituent  Configuration  Items 
(CIs)  forming  a  system.  Each  Cl 
is  defined  by  •  performance 
specification  which: 

(1)  defines  Cl  functional 
characteristics  including 
those  allocated  from  the 
system  specification, 

(2)  delineates  interface  re¬ 
quirements  of  CIs, 

(3)  establishes  criteria  to 
demonstrate  that  required 
Cl  performance  has  been 
achieved,  and 

(k)  establishes  design  con¬ 
straints. 

c.  Product  Baseline:  Established 
for  each  Cl  upon  couplet loo  of 
the  audit  of  the  physical  and 
functional  characteristics  of 
the  item.  For  CIs  developed  as 
s  result  of  Company  funded  In¬ 
dependent  Research  and  Develop¬ 
ment  (IRAD)  effort,  this 
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C.  DEF1IUT10HS:  (Confd) 

baseline  is  established  after 
completion  of  any  tests  required 
to  demonstrate  the  Item's  suit¬ 
ability  for  customer  procure¬ 
ment  .  The  product  baseline  is 
defined  by  specifications,  in¬ 
cluding  referenced  design  draw¬ 
ings  which  describe: 

(1)  physical  characteristics  re¬ 
quired  to  oanufacture  and 
reprocure  the  Cl , 

(2)  the  selected  functional 
characteristics  of  the  Cl 
designated  for  product  ac¬ 
ceptance  testing,  and 

(3)  the  production  acceptance 
tests. 

2.  Configuration:  A  collection  of  a 
product's  descriptive  and  governing 
characteristics. 

a.  In  functional  terms,  the  perfor¬ 
mance  it  is  expected  to  achieve. 

b.  In  physical  terms,  what  it 
should  look  like  and  consist  of. 

3.  Configuration  Control  Board  (CCB): 

A  board  appointed  by  the  Program 
Manager  for  a  given  program  to  re¬ 
view  all  proposed  specification  and 
design  changes  for  necessity,  cost 
and  effectivity.  The  CCB  consists 
of  the  Configuration  Manager  and 
other  permanent  members  from  Custom¬ 
er  Contracts,  Engineering,  Manufac¬ 
turing,  Material,  Product  Support 
and  Quality  Assurance  Divisions, 
and  program  management.  Other 
organisations  will  be  represented 
as  required  for  support.  The  CCB 

is  a  noc voting  board  with  the  chair¬ 
man  responsible  for  final  decision 
on  all  CCB  actions.  Scheduled 
meetings  will  be  held  and  the  board 
nay  be  convened  by  the  Chairman  for 
special  sessions  as  required. 


*•.  Con fl gyration  identification:  The 
current  approved  or  co-  i.ti^nallv 
approved  technical  documentation 
for  a  Cl  as  set  forth  in  specifica¬ 
tions,  drawings  and  associated 
lists,  and  documents  referenced 
therein. 

5.  Configuration  Iten  (Cl):  An  aggre¬ 
gation  of  hardware/softvare ,  or  any 
of  its  discrete  portions,  which 
satisfies  an  end  use  function  and 
is  designated  by  the  government  for 
CM.  During  development  and  initial 
production,  Cls  are  only  those 
specification  items  that  are  spe¬ 
cifically  referred  to  in  the  con¬ 
tract.  During  the  operation  and 
maintenance  period,  any  repairable 
itec  designated  for  separate  pro¬ 
curement  is  a  Cl. 

6-  Configuration  Management  (CM):  A 
discipline  applying  technical  and 
administrative  direction  and 
surveillance  to: 

a.  identify  and  document  the 
functional  and  physical  charac¬ 
teristics  of  a  Cl, 

b.  control  changes  to  those 
characteristics,  and 

c.  record  and  report  change  pro¬ 
cessing  and  implementation 
status. 

T.  Configuration  Status  Accounting 
(CSA): The  recording  and  reporting 
of  the  information  that  is  needed 
to  manage  configuration  effective¬ 
ly,  including  a  listing  of  the 
approved  configuration  identifica¬ 
tion,  the  status  of  proposed 
changes  to  configuration,  and  the 
implementation  status  of  approved 
changes. 

8.  Functional  Configuration  Audit 
(FCA):  A  wans  of  validating  that 
development  of  a  Cl  has  been  com¬ 
pleted  satisfactorily.  FCAs  shall 
be  conducted  to  assure  that: 


Version  1.01 


Page  37 


NO:  CP  2.001 

Pact  3  of  6 
0A1(  9  Dec  69 


C.  DEFINITIONS:  (Cool'd) 

•.  te*t  data  for  a  Cl  verify  the 
item  ha*  achieved  the  perfor¬ 
mance  specified  in  its  functional 
or  allocated  configuration  iden¬ 
tification,  and 

b.  technical  docuaentation  is  main- 
tained  describing  the  physical 
configuration  of  each  unit  of 
the  Cl  for  which  test  data  is 
verified. 

9.  Functional  Configuration  Identifi- 


catior.  (FCI):  Current  approved 


technical  docuaentation  for  a  Cl 

which  prescribes: 

a.  all  necessary  functional 
characteristics ; 

b.  tests  required  to  deaonstrate 
achievement  of  specified  func¬ 
tional  characteristics; 

c.  necessary  interface  character¬ 
istics  with  associated  CIs; 

d.  lower  level  CIs,  if  any;  and 

e.  applicable  design  constraints, 
if  any. 

10.  Phase: 

a.  Definition  Phase:  The  formula- 
tive  stage  in  the  evolution  of  a 
system  during  which  major  trade¬ 
offs  are  accomplished  and  the 
need  for  a  capability  is  trans¬ 
lated  into  a  system  specifi¬ 
cation  and  into  performance 
requirements  for  individual  CIs 
as  required  by  Department  of 
Defense  (DoD). 

b.  acquisition  Phase:  The  period 
in  the  life  cycle  of  an  opera¬ 
tional  system  eoMencing  with 
customer  issuance  of  an  updated 
system  specification  (end  of 
definition  phase).  During  this 
phase,  the  system  is  designed 


and  developed;  its  identifica¬ 
tion  documentation  is  expanded 
and  reviewed  until  completed  and 
formally  approved.  Acquisition 
phase  continues  until  the  accep¬ 
tance  by  the  customer  of  the 
last  operating  unit  in  a  series. 
Development  portion  of  the  ac¬ 
quisition  phase  is  concluded 
when  the  specified  requirements 
have  been  demonstrated  through 
Category  II  testing  and  all 
required  updating  changes  re¬ 
sulting  from  the  testing  have 
been  identified,  approved  and 
placed  on  procurement,  whichever 
occurs  later. 

c .  Operational  Phase:  The  phase 
for  any  single  Cl  beginning  with 
the  delivery  of  the  first  unit 
of  the  Cl  to  be  accepted  for  the 
operational  inventory. 

11 •  Physical  Configuration  Audit  (PC*): 
A  means  of  establishing  the  Product 
Configuration  Identification  (PCI) 
used  initially  for  production  and 
acceptance  of  the  units  of  a  Cl. 

DoD  will  assure  (through  PCAs) 
that: 

a.  the  "as  built"  configuration  of 
a  unit  of  a  Cl,  selected  Jointly 
by  the  DoD  component  and  MCAIR. 
matches  the  same  unit's  PCI  as 
proposed  by  MCAIR,  or  that  dif¬ 
ferences  are  reconciled;  and 

b.  the  acceptance  test  requirements 
prescribed  by  the  documentation 
are  adequate  for  acceptance  of 
production  units  of  a  Cl  by  Qual¬ 
ity  Assurance  Division  fuacticas. 

12.  Product  Configuration  Identifica¬ 
tion  (PCl):  The  current  approved 
or  conditionally  approved  technical 
documentation  which  defines  the 
configuration  of  a  Cl  during  the 
production,  operation,  maintenance 
and  logistic  support  phases  of  its 
life  cycle,  and  which  prescribes: 
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-.  DEFINITIONS:  (Cont'd) 

a.  oil  necessary  physical  or  "fora, 
fit  and  function"  characteris¬ 
tic*  of  a  Cl; 

b.  the  selected  functional  charac¬ 
teristics  designated  for  pro¬ 
duction  acceptance  testing;  and 

c.  the  production  acceptance  tests. 

13.  Specifications : 

a.  System  Specification:  States 
the  technical  and  mission  re¬ 
quirements  of  the  system  as  an 
entity.  These  specifications 
include: 

(1)  necessary  performance  re¬ 
quirements,  including  test 
provisions  to  assure  that 
all  requirements  are 

f  achieved; 

(2)  essential  physical  con¬ 
straints;  and 

(3)  requirements  for  specific 
functional  areas,  interfaces 
between  functional  areas, 
interfaces  with  other  sys¬ 
tems,  and  application  of  any 
known  specific  existing 
equipment. 

b.  Development  Specification: 

States  all  necessary  requirements 
in  terms  of  performance.  These 
requirements  Include: 

(1)  essential  physical  con¬ 
straints  for  the  development 
of  CIs,  other  than  systems; 
and 

(2)  functional  characteristics 
and  tests  required  to  demon¬ 
strate  achievement  of  those 
charact er i st ic s . 


c .  Product  Specification:  States 
functional  requirements  and  phys¬ 
ical  characteristics  necessary 
to  procure  either  CIs  requiring 
"form,  fit  and  function"  Inter¬ 
changeability  or  identical  Items 
within  specification  tolerances. 
The  specifications  specify  all 
the  quality  assurance  provisions 
necessary  to  adequately  demon¬ 
strate  achievement  of  the  speci¬ 
fied  requirements  and  character¬ 
istics. 

It.  System:  A  composite  of  subsystems, 
assemblies,  skills  and  techniques 
capable  of  performing  and/or  sup¬ 
porting  an  operational  role.  A 
complete  system  Includes  related 
facilities,  items,  material,  ser¬ 
vices  and  personnel  required  for 
its  operation  to  the  degree  that  it 
can  be  considered  a  self-sufficient 
item  in  its  intended  operational 
and/or  support  environment. 

D.  REGULATIONS: 

1.  CM  will  be  established  as  prescribed 
in  DoD  Directive  5010.19,  Configura¬ 
tion  Management  and  DoD  Instruction 
5010.21,  Configuration  Management 
Implementation  Guidance. 

2.  CM  will  satisfy  MIL-STD-J18O  and/or 
MIL- STD -1*81,  Configuration  Control  - 
Engineering  Changes,  Deviations  and 
Waivers;  use  the  standard  data  ele¬ 
ments  of  MIL-STD-J*82,  Configuration 
Status  Accounting  Data  Elements  and 
Related  Features;  and  satisfy  MIL- 
STD-L90,  Specification  Practices, 
and  KIL-STD-Sjk'X) ,  Specifications, 
Types  and  Forms,  as  contractually 
invoked . 

3.  During  the  definition  phase.  CM 
will  be  accomplished  at  system 
level.  Formal  CM  will  be  imple¬ 
mented  early  in  the  definition 
phase  when  the  system  specification 
has  been  contractually  imposed  on 
HCAIR. 
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D.  KECULATI055:  (Cont'd) 

k.  During  the  acquisition  phase,  em¬ 
phasis  will  be  on  configuration 
control  and  statu*  accounting.  <31 
is  expanded  to  include  accooplish- 
aent  at  the  Cl  level. 

5.  With  the  beginning  of  the  opera¬ 
tional  phase,  formal  CSA  reporting 
to  the  DoD  component  tracks  the 
product  baseline  as  well  as  other 
specific  requirements  imposed  by 
the  cognizant  customer  agency  and 
MCA IB  management. 

6.  The  Configuration  Manager  is  re¬ 
sponsible  for  ensuring  that  con¬ 
figuration  identification,  control 
and  accounting  are  implemented  in 
compliance  with  contract  require¬ 
ments.  Additionally,  he  shall  be 
responsible  for  administration  of 
the  CCB. 

E.  PROCEDURE  1:  PROGRAM  IMPLPtENTATIOW 

Engineering  Divisions 

l.  Receive  DoD  request  for  expansion 
of  system  specification  or  deter¬ 
mine  that  MCAIR  preparation  of 
system  specification  will  enhance 
program  sales  effort  in  support  of 
an  unsolicited  program. 

Customer  Contracts  Division 


Program  Manager 

k.  Coordinate  the  appointment  of  a 
Configuration  Mareger  with  Manager 
Contract  Management  Systems . 

5.  Appoint  members  to  CCB  and  desig¬ 
nate  chairman. 

Engineering  Divisions 

6.  Prepare  or  update  system  specifica¬ 
tion  utilizing  customer  supplied 
system  oriented  documentation  sub¬ 
mitted  by  Customer  Contracts  Divi¬ 
sion  and  forward  to  Configuration 
Manager. 

Configuration  Manager 

7.  Review  information,  record  changes 
and  update  CM  records  and  forward 
to  Customer  Contracts  Division. 

Customer  Contracts  Division 

8.  Submit  system  specification  to 
appropriate  requesting  agency  for 
approval  or  Joint  resolution; 
refer  results  with  implementation 
directions  regarding  designated 
CIs  to  Configuration  Manager  (be¬ 
ginning  of  Phase  IB,  definition 
phase  and  thus  establishing  func¬ 
tional  baseline). 

Engineering  Division 


2.  Receive  notification  from  customer 
agency  via  a  Request  for  Proposal 
(RFP) ,  contract  change  order, 
statement  of  work,  etc.,  that  MCAIR 
is  assigned  responsibility  to 
update  and  expand  a  system  speci¬ 
fication  (beginning  of  Phase  IA 

of  definition  phase). 

3.  Document  authorization  to  proceed 
with  expansion  of  system  specifica¬ 
tion  and  forward  to  the  designated 
program  or  engineering  manager. 


9.  Prepare  updated  system  specifica¬ 
tion  baaed  on  that  version  received 
at  tbe  start  of  Phase  IB.  Prepare 
development  specifications  for  CIs, 
critical  item  specifications  when 
required  and  specification  tree  to 
reflect  specific  program  specifica¬ 
tion  activity  proposed  or  required 
for  each  program.  Submit  package 
to  Configuration  Manager. 
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E.  PROCEDURE  I:  PROG  RAH  IMPLEMENTATION 

(Cont*d) 

Configuration  Manager 

10.  Monitor  specification  preparation 
activity,  collect  and  docuaent  CM 
requirements  and  establish  trace- 
ability  of  Customer  requested 
changes  to  the  affected  systes 
specification  received  at  start  of 
Phase  18. 

11.  Review  and  determine  long-range 
specification  programs;  coordinate 
expanded  specification  program  per 
contract  requirements. 

12.  Insure  change  control  traceability. 

13-  Coordinate  the  analysis  of  CM  re¬ 
quirements  vith  respect  to  appli¬ 
cability  to  subcontractors  and 
assure  release  of  proper  definition 
of  same  for  incorporation  in  MAC  877 
(Series),  PURCHASE  ORDER,  or  RFP. 

14.  Rerlev  information  and  related 

change  control  documentation  (Engi¬ 
neering  Change  Proposal  (ECP)  and 
related  Specification  Change  no¬ 
tices)  and  schedule  a  meeting  of 
the  CCB. 

CCB 

15-  Review  and  approve  updated  system 
specification  and  related  change 
documentation.  Forward  to  Customer 
Contracts  Division. 

Customer  Contracts  Division 

16.  Accumulate  inputs  from  all  partic¬ 
ipating  project  areas  to  satisfy 
requirements  of  RFP;  submit  proposal 
to  cognizant  requesting  agency,  com¬ 
pleting  Phase  IB  of  definition  phase. 

Configuration  Manager 

17.  Coordinate  and  expand  activities 
of  participating  project  arets  to 
further  refine  CM  functions,  as  re¬ 
quired,  to  enable  implementation  as 
proposed  in  Phase  IB  (Phase  IC  of 
deflnltloo  phase). 


Customer  Contracts  Dlvlslcf: 

18.  Receive  award  for  Phase  11  contract 
(acquisition  phase);  review  contract 
for  funding  and  scope  cf  work. 

NOTE:  Customer  approval  of  those 
development  specifications  sub¬ 
mitted  as  part  of  the  proposal,  or 
award  of  Phase  IX  contract  estab¬ 
lishes  the  allocated  baseline. 

19-  Issue  MAC  751*,  JOB  ORES,  reflect¬ 
ing  necessary  funding  and  con¬ 
tractual  authorizations  for  sched¬ 
uled  implementation  and  expendi¬ 
ture  of  time  ar.d  material  as  pre¬ 
scribed  in  CP  7.101. 

Engineering  Division 

20.  Complete  detail  design  and  prepare 
necessary  production  dr awing*. 

21.  Prepare  product  specifications  con¬ 
sidering  negotiated  trade-offs  from 
design  reviews. 

22.  Support  CM  requirements  throughout 
operational  phase  and  production. 
Production  items  will  reflect  the 
requirements  of  PCI  cumentation, 
plus  any  approved  changes  thereto. 

Manufacturing  Division 

23.  Receive  drawings  from  Engineering 
Division;  follow  up  as  necessary  to 
assure  that  drawings  and  revisions 
thereto  are  released  on  schedule. 

2k.  Translate  drawings  into  shop  work 
instructions  for  manufacture  of 
required  tools,  parts  and  assem¬ 
blies. 

23.  Maintain  a  detailed  drawing  config¬ 
uration  record  for  traceability 
and  audit  of  configuration  for  each 
drawing. 

26.  Maintain  an  "as  planned"  bill  of 
material  and  audit  to  the  "as  de¬ 
signed"  bill  of  material  as  re¬ 
quired  to  assure  equivalence. 
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E.  PROCEDURE  I:  PROGRAM  IMTLPtECATI  OH 

(Cont’d)  ” 

27.  Maintain  historical  record  of  shop 
work  Instruction  releases  to  verify 
manufacture  of  proper  configuration 
for  effectlvity  and  schedule. 

28.  Manufacture  hardware  and  obtain 
Quality  Assurance  Division  certi¬ 
fication  of  configuration  and 
quality. 

29-  Control  installation  of  Cl  serial¬ 
ised  items  by  effectlvity  and 
assigned  serial  numbers. 

30.  Participate  in  configuration  re¬ 
views  and  audits. 

Material  Division 

31.  Requisition  and  procure  the  re¬ 
quired  configuration  on  all  parts, 
systems,  and  assemblies  from  sup¬ 
pliers,  in  accordance  with  CP 
6.105  and  CP  6.106;  and  approved 
in  accordance  vith  CP  6.101. 

32.  Impose  on  all  suppliers,  CM  prac¬ 
tices  and  requirements  including 
supplier  control  and  certification 
of  CIs  for  conformance  to  estab¬ 
lished  baselines,  through  PURCHASE 
ORDER  and  clauses. 

Quality  Assurance  Division 

33.  Perform  continuous  hardware  audit 
to  ensure  the  "as  built"  configu¬ 
ration  conforms  to  the  "as  de¬ 
signed"  configuration. 

3b.  Verify  and  document  the  first  in¬ 
corporation  of  each  Class  I  engi¬ 
neering  change. 


incorporation  records  as  an  inte¬ 
grated  record  system  in  which  eact 
Cl  is  visible  and  auditable. 

37.  Provide  integrated  record  system 
data  as  a  primary  input  for  PCA, 
supplemented  by  the  product  speci¬ 
fication  and  top  level  engineering 
drawings  and  change  documents  ref¬ 
erenced  therein,  from  engineering 
files  foi  hardware  verification. 
Drawings  subindentured  to  top  level 
drawings  should  be  available  in 
file  in  case  they  are  needed. 

38.  Assure  conformance  of  subcontractor 
and  supplier  to  CM  requirements  it 
PURCHASE  ORDER. 

Product  Support  Division 

39-  Maintain,  for  cognizant  requesting 
agency,  CM  serial  number  records  of 
items  selected  for  serialized  ac¬ 
counting. 

b0.  Prepare  and  submit  data  to  intro¬ 
duce  items  selected  by  the  cogni¬ 
zant  requesting  agency  for  serial¬ 
ized  accounting,  in  accordance  vith 
contract  requirements. 

bl.  Submit  data  relating  serial  numbers 
of  each  selected  item  to  its  next 
higher  assembly  serial  number  and 
the  operating  time  for  each  item, 
in  accordance  vith  contract  re¬ 
quirements  . 

b2.  Prepare  and  maintain  other  docu¬ 
mentation  required  to  provide 
logistics  support  to  the  system  or 
system  segment  being  procured  by 
DoD. 

b3.  Coordinate  retrofit  programs . 


35.  Verify  mod  record  serial  numbers  of 
items  selected  for  serialized  ac¬ 
counting. 

36.  Provide  and  maintain  Quality  Assur¬ 
ance  records,  selected  items  con¬ 
figuration  log  and  Class  I  change 


bb.  Prepare  and  coordinate  ECP  sched¬ 
ules  and  milestone  charts.  Inte¬ 
grated  Logistics  Support  (ILS) 
documents  and  ECP  supporting  ex¬ 
hibits  for  ILS  purposes. 
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E.  PROCEDURE  I:  PROGRAM  IMPLEMENT ATI OR 
(Coot’d) 

lt5.  Provide  and  maintain  CSA  data  and 

reports  in  accordance  with  CM 

requirements  of  the  contract. 

F.  REFERENCES : 

1 .  Central 

a.  CP  6.101,  Routing  and  Approval 
of  Purchase  Requisitions 

b.  CP  6.105,  Purchase  Requisitions 

c.  CP  6.106,  Purchase  Orders  and 
Purchase  Change  Orders 

d.  CP  7.101,  Job  Orders 

e.  DoD  Directive  5010.19,  Config- 
uration  Management 

f.  DoD  Instruction  5010.21,  Config¬ 
uration  Management  Implementa¬ 
tion  Guidance 


g .  M2L-STD-lt80,  Configuration  Con¬ 
trol  -  Engineering  Changes,  De¬ 
viations  and  Waivers 

h.  MII/-STD-J<8l,  Configuration  Con¬ 
trol  -  Engineering  Changes,  De¬ 
viations  and  Waivers  (Short 
Form) 

i.  MIL- STD-1*  82,  Configuration  Sta¬ 
tus  Accounting  Data  Elements 
and  Related  Features 

J.  M1D-STD-1*90,  Specification 
Practices 

k.  MIL- STD-831*  90,  Specifications, 
Types  and  Forms 

2.  Forms 

a.  MAC  751*,  Job  Order 

b.  MAC  877  (Series),  Purchase  Order 


A.  L.  Boyd 
Vice  President 
Fiscal  Management 
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AOTS  UNIQUE  FORMS 


Form  Number 

Description 

Rev. 

Date 

AOTSOOlO-1 

AOTS  Project  Specification 
Change  Memo 

— 

8/26/86 

AOTSOOlO-4 

AOTS  Estimate  Work  Sheet 
Summary 

— 

9/22/86 

AOTSOOlO-5 

AOTS  Estimate  Subsystem 

Work  Sheet 

— 

9/22/86 

AOTS0010-6 

AOTS  Configuration  Control 
Form 

— 

9/22/86 

AOTSOOlO-8 

Configuration  Item  Development 
Record  - 

9/23/86 

AOTSOOIO-IO 

Hardware  Configuration  Item 

— 

9/24/86 

AOTSOOlO-11 

Engineering  Change  Classification 
Checklist  - 

9/23/86 

AOTSOOlO-12 

Risk  Analysis  Worksheet 

— 

10/1/86 

AOTSOOlO-13 

Risk  Analysis  Worksheet 
Summary 

— 

9/25/86 

AOTS 00 10- 14 

Engineering  Release  Form 

— 

10/1/86 

AOTSOOIO— 15 

CM  Control  Log 

— 

10/1/86 

A.OTSOOlO-16 

Computer  Program  Configuration 
Item  - 

10/2/86 

AOTSOOlO-17 

CPCI  Continuation  Form 

— 

10/2/86 

AOTSOOIO— 18 

Change  History  Continuation 
Form 

— 

10/2/86 

AOTSOOlO-19 

Configuration  Item  Audit  and 
Review  Record 

— - 

10/2/86 

AOTSOlOO-1 

AOTS  Maintenance  Action 
Report 

— 

8/25/86 

AOTSOlOO-4 

Software  Problem  Report 

— 

8/25/86 
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GOVERNMENT  FORMS  USED  BY  AOTS 


DD  1693  Engineering  Change  Proposal  (Short  Form)  MIL-STD-481A 

DOD-STD-4  8  OA 

-OR-  DD1692-1  Engineering  Change  Proposal  (long  form) 

DOD-STD-4 8  OA 

DD  1694  Reguest  for  deviation/waiver  MIL-STD-481A 

DOD-STD-4 8 OA 

AFSC  223  Advanced  Change/Study  Notice  (ACSN)  MIL-STD-483A 

none  specified 

Contract  Change  Proposal/Task  Change  Proposal 


MIL-STD-483A 


DD  1696  Specification  Change  Notice  (when  spec  is  revised) 

MIL-STD-433A 
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AOTS  PROJECT  SPECIFICATION  CHANGE  MEMO  |  no. 

I  DateT 


|  Fro*: 


| Affected  Specs: 

|(]  A  Spec  70S647000 

i  n  bi  spec  # _ 

| [ j  B5  Spec  # _ 

| [ ]  C5  Spec  # _ 

j[]  other  document (s) 


Telephone  #: _ 

R«aark*s 


|  Affected  software: 
I 

| Affected  hardware: 


| Description  of  change: 


change.) 


j CHANGZ  CLASSIFICATION  (Set  by  Configuration  Control): 
It)  Class  1  (]  Class  2  (]  Other:  _ 


|  APPROVAL  OP  CHAMOIS 


(]  Approved  [ )  Disapproved 


j  Subsystem  Manager 

MDAC  Configuration 

MDAC  Program  Manager 

1 

Control  Manager 

|  AT  APPROVAL: 


i AF  Configuration  ControlAF  T 


| Date  for  specs  to  be  updated  by: 


(]  Approved  (]  Disapproved 


A P  Program  Manager 


AOTSOOlO-1  (Rev. 


J  Aug  2«,  1986 


cm  Page  47 


AOTS  ESTIMATE  WORK  SHEET  SUMMARY 


ESTIMATE  SECTION:  (Use  additional  pages  as  necessary) 

_  MHrs  $ _ 


MHrs  $ 


1 

1 

1ST. Support: 

MHrs  $ 

1 

Schedule  Impact: 

1 

TODS  Subsystem: 
Schedule  Impact: 


MHrs  $ 


Personnel  Subsystem 
Schedule  Impact: 


MHrs  $ 


Computer  Support  Subsystem: 
Schedule  Impact: 


Spread  of  labor  per  subsystem  CPCI 
Management:  _ 


Evaluation 


TDOS 


Support 
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AOTS  CONFIGURATION  CONTROL  FORM 


|  CM  Log  Mo.  _ 

j  originator  (or  sourca) 


]  (]  Class  1  (]  Class  2  []  Othar 

|  impact  statsmant:  _ 


|  Change  Sourca:  _ 

j  Affactad: 

j  Specification (s) : _ 

|  HWCI(s):  _ ' 

|  CPCI(s) :  _ _ _ 

I  Affactad  Basal ina  Varsion: 


|  Risk  Analysis  stataaant 


varsion:  | 


Bata  Varsion: 


MHra 

9  (Material)  I 

i 

| 

l 

l 

ition  to  documant  cost 


Schadula: 


|  (Attach  supporting 
I  impacts.) 


|  APPROVALS: 


I  C)  Approved  []  Oisapprovad  -  Implamant  othar:  _ 

I  (la  scope  only  change 

|  MDAC  CCB  PM:  _ _  AF  CCB  PNl  _ 

I  Data:  7  7  Data: 


I  H  Approved  []  Disapproved  Implamant  Class  2  (in  scope)  change | 


Oates 


[]  Approved  (]  Disapproved  -  Tfnr—sni  Impl ament ing  class  1 

(oat  of  scope)  change 

MDAC  CCB  PM:  _______  AF  CCB  PM:  _ 

Dates  /  /  Dates  /  / 

It  approved,  Engineering  Change  Proposal  (BCP)  suit  be 
prepared  an*  forwarded  to  AOTS  AF  Contracting  Officer  for 
approval  prior  to  proceeding.  Date  sent  to  MDAC  GO  for  BCP 

preparations  /  ✓ _  Date  sent  to  AF  CO:  /  / 

(]  Approved  [)  Disapproved  by  Air  Force  contrac€2ng  Officer 
Dates  /  /  MDAC  Authorisation  (charge  numbers 


Dat 

a  sent  to  ei 

mm mbmmh 

Dat 

a  for  releai 

ie  of  changes 

/  / 

in  versions 

Dat 

ennKinaMEiB 

jgjjgi 

liens  /  J 

Ram 

SSSBS 

Aorsooio-s  (Rev 


Sept.  22,  19M  cm2 


AOTS  CONFIGURATION  CHANGE  REQUEST 


[]  Approved  to  proceed  []  Disapproved  (return  to  file  and  copy| 

originator)  I 

Authorized  by:  _  Date:  _ _ / _ / _  | 
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CONFIGURATION  ITEM  DEVELOPMENT  RECORD  -  PART  1 


Nomenclature: 


Development  Specification: 
Number  and  Date: 
Authentication  Date: 


Configuration  Item: 
Identification: 


Preliminary  Design  Review  I  Critical  Design  Review 

Date:  j  Date: 

I 

- — — — — — f— - — - — - 

Functional  Configuration  |  Physical  Configuration 

Audit  -  Schedule  Date:  j  Audit  -  Schedule  Date: 

I 

I 

—  —  —  —  —  —  —  —  —  —  —  —  —  —  —————  —  —  —  —  —  — —  —  —  —  — —  —  —  — 

Configuration  Item  Qualification  Scheduled  Date: 


Qualification  Test  Report: 


Contractor:  1  Contract  No. 

I 

’c0NRGUFfATI0N7f^ 


Configuration  Item  |  Impact  of  Changes  on  Related  CIs 

Specification  j 


SCN  | 

1 

ECP  | 

| 

Sepecificat ion/ Document  | 
Title  and  Number  j 

SCN  | 

1 

- 1 

ECP  |  CONTR| 

i  j 

i  i  i  i  i  i 

AOTSOOlO-8  (Rev. _ )  sept.  23,  1986 
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AOTSOOlO-9  (Rev. 001)  Oct.  13,  1986 
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ENGINEERING  CHANGE  CLASSIFICATION  CHECKLIST 


Cl:  _ 

Part  Number: 
Description: 


YES  |  NO  | 


CM  Log  No. 


CRITERIA  (NOT  LIMITED  TO  THE  FOLLOWING) 


1.  Are  you  recommending  retrofit? 


2.  Does  this  correct  a  deficiency  (specs  or  rqt) 


AOTSOO 10—11  (Rev. _ )  Sept  23,  1986 
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RISK  ANALYSIS  WORKSHEET  SUMMARY 


AOTS  CM  Log  Number: 


Effected  Areas: 

[]  SOW 
[ ]  Cost 

[]  Delivery  Schedule 
[ ]  Documentation 
t ]  Safety 
[ 3  Manpower  level 


Contractor  Position: 


Contract  [  3 

Fee  [  3 

Development  Schedule 
Specifications  [3 

External  Interfaces 
Skill  level  [3 


Proposal 
Cost  to  Gov’t 

Operations 

Training 


|  Analysis  performed  by 
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RISK  ANALYSIS  WORKSHEET 


AOTS  CM  Log  Number:  _ 

Prepared  by: 

[J  Air  Force  []  Contractor: 


Effected  Areas: 

[]  SOW 
[]  Cost 

[]  Delivery  Schedule 
[ ]  Documentation 
[  ]  Safety 
[ ]  Manpower  level 


Contract  [  ] 

Fee  [] 

Development  Schedule 
Specifications  [] 

External  Interfaces 
Skill  level  [] 


Proposal 
Cost  to  Gov't 

Operations 

Training 


Analysis  performed  by 


AOTSOOlO-12  (Rev. 


Oct.  1,  1986 
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ENGINEERING  RELEASE  FORM 


|  AOTS  CM  Log  No.  _ 

Affected  CPCI : 

Affected  HWCI :  _ 

Affected  Specif ication(s) 
Affected  Document (s) : 


Release  Date: 


Description  of  work 


BUDGET:  []  Single  Task  []  Multiple  Tasks  (Qty: 

Authorized  manhours:  _  Material  $ _ 

Authorized  charge  number (s)  for  manpower  per  task: 

Task  1  _  MHrs:  CAM:  _ 

Task  2  _  MHrs:  CAM:  _ 

Task  3  _  MHrs:  CAM:  _ 

Authorized  charge  number (s)  for  material:  _ 


work  assigned  to:  __ 
Assigned  Supervisor 


Date  work  is  to  be  completed: 

Date  testing  to  start: 

Date  Beta  testing  to  start: 
Estimated  Date  to  formal  release: 


Estimated 


Actual 


The  attached  schedule  shall  be  used  for  this  effort 


Remarks 


APPROVALS :  Charge  Numbers : 


For  implementation: 


AOTS  Program  Manager 


AOTSOOlO-14  (Rev.  )  Oct.  1,  1986 
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COMPUTER  PROGRAM  CONFIGURATION  ITEM 


CPCI  No.  and  Nomenclature 


j  Software  Requirements  Specification:  _ 
|  Date  of  Issue:  / _ / _  Rev.  No. 


I 

|  Software  Top  Level  Design  Document:  _ 

j  Date  of  Issue:  _ / _ / _  Rev.  No. 


|  Sheet  _  of  _  |  Issued  by 


AOTSOO 10-16  (Rev.  )  Oct.  2,  1986 


_  Date 


» 
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CPC  I  CONTINUATION  FORM 


CPCI  No.  _  |  Issue  date:  _ / _ / 


Nomenclature: 

"  | 

Program/Subroutine  names  used 
NAME  Date 

in  this  CPCI: 

Rev.  Description 

1 

— 

Change  History: 


Sheet  _  of  _  |  Issu’d  by:  _  Date: 


AOTSOO 10-17  (Rev. _ )  Oct.  2,  1986 
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CHANGE  HISTORY  CONTINUATION  FORM 


|  Sheet 


AOTSOOlO-18  (Rev. _ )  Oct.  2,  1986 
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CONFIGURATION  ITEM  AUDIT  AND  REVIEW  RECORD 


[]  CI  #  _  []  CPCI  # 


nomenclature: 


Specification  Review 
Date:  _ / _ / _ 


Preliminary  Design  Review 
Date:  _ / _ / _ 


Critical  Design  Review 
Date :  _ / _ / _ 


Test  Readiness  Review 
Date:  _ / _ / _ 

Functional  Configuration  Audit 

By:  _  Date: 

Physical  Configuration  Audit 

By:  _  Date: 

Applicable  Specif ication(s) 


Applicable  Documentation 


Remarks : 
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AOTS  MAINTENANCE  ACTION  REPORT  FORM 


LOG  NUMBER: 


DATE: 


LOCATION : 


NAME:  _ 


TYPE  OF  EQUIPMENT: 
[]  HP  Laser jet+ 

[ ]  IBM  PC  AT  XT 
[]  DEC  VAX  8600 


[]  Zenith  Z-248  PC 
[ ]  Color  printer 
[ ]  Infotron  Comm 
[]  Other:  _ _ 


TIME: 


[ ]  Dot  Matrix  Printer 
[]  Data  Tablet  11  X  11 
[]  Data  Tablet  20  X  20 


Serial  Number: 


Other  ID#: 


Description  of  failure: 


Problem  reported  to  (responsible  for  maintenance) : 


Date: 


Time: 


REPAIR  ACTION:  Date  maintenance  started 


Date  finished: 


Time: 


[]  On-Site  []  Off-Site  Name: 
Organization:  _ 


Corrective  Action: 


Time  Taken  to  repair 


Time  awaiting  parts 


Is  the  configuration  of  the  item  changed  during  maintenance?  []  Yes  []  : 
If  yes,  describe  and  document  revision  level  changes  and  effected  items 


Acceptance  of  repaired  item  name  and  signature: 
Certified  by  (name  and  signature) :  _ 


AOTS  0100-1  (Rev.  _ )  Aug.  25,  1986 
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SOFTWARE  PROBLEM  REPORT 


Log  No. 


Name: 


Date: 


Time: 


Location: 


Telephone  number:  _ 


Hardware  being  used  when  problem  was  detected:  []  Z248  [j  8600 
[]  Other:  _ 

Description  of  problem:  _ 


Problem  assigned  to: 


Date: 


Classification:  []  Bug  []  User  Error  []  Class  1  (Enhancement) 

Priority:  []  Immediate  (]  Delayed  []  Workaround  []  Other:  _ 

Corrective  action: 


Date  work  completed: 


CM:  [)  CM  Entered  (]  CCB  approved  []  CM  Action: 


Corrective  action  approval 


Software  Manager 


Configuration  Mgt. 


Program  Manager 
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£  CONFIGURATION  ITEM  LIST  -HWCI-  15-Oct-86 
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HAAOUARE  CONFIGURATION  ITEM  LIST  -HWCI-  15*Oct*86 


S5200-A4  I  A  78  I  Reserved  for  phase  III  i  TDOS 


HARDWARE  CONFIGURATION  ITEM  LIST  -HUCI-  TS0ct-86 


